The Part and Family System manages part definitions in catalogs that contain duplicate family names. The order in which the XML part files are processed determines which part definition takes precedence (generally, the first one processed “wins”). This order can be determined by the load sequence defined in TFDIR_PART for parts, TFDIR_CPART for compound parts, and TFDIR_COMP for components. The first part to be defined is the one that takes precedence. The default load sequence forces project part files and definitions to take precedence over dataset parts files and definitions.

The current default behavior for the Part and Family System is to generate a family and part list purely based on the order in which families are defined. Once a family is defined, it will only accept part definitions associated to that family defined within that file. If another file contains the exact same family name and offers a list of additional parts, that family and its associated parts are not processed, since it is classified as a duplicate family.

Concatenation of the Part and Family System changes how the family and part list is generated. The load order is still pertinent in determining which part file takes precedent, but additional family and part definitions are taken into consideration. As additional part files are read and duplicate families are identified, the parts assigned to that duplicate family are now evaluated. Parts with the same name are marked as duplicate parts and are ignored while new part definitions are appended to the family.

Concatenation of the Part and Family System enables you to easily manage and append delivered Building datasets in the Family/Part Editor. Parts can be defined in different XML files while sharing a common family name. This permits you to extend the part definitions for each project while leveraging a core list of parts from the dataset. Also, this gives you the option to selectively override core part definitions with a project definition. This applies to families of single parts, compound parts, and components.

An additional benefit of Concatenation is that it enables parts, acting as unifier parts, to be stored in multiple XML files when they share the same family name.

The Family/Part Editor uses color coding to show which parts and families are duplicates and which parts and families are active. Duplicate families are indicated by blue text, and duplicate and unused part definitions are indicated by red text.

To enable Concentrations of Parts and Families, set the configuration variable TFDATASET_SHOWDUPLICATEFAMILIES to a value of 1.